In some microcontrollers, bus masters are connected to bus slaves fully or partially through one or more bus matrix ports and switches. In these microcontrollers, data transfer requests from the masters to the slaves have to pass successively through several arbitration nodes. At any time, a given master may have several pending data transfer requests. Each of these transfer requests may have a dynamically changing urgency based on latency and/or bandwidth requirements.
Bus arbitration is used in these microcontrollers to meet each master's bandwidth and latency requirements and to maximize the overall available bandwidth of the system. In these microcontrollers, the arbitration nodes often arbitrate conflicts locally in the network space and only once at each arbitration node using a priority value that is statically associated with the data transfer request. Regardless of the priority of a data transfer request at any given arbitration node, the progress of the data transfer request to the target slave is dependent on the progress of the preceding transfer request at the next downstream arbitration node.
One solution to the congestion problem is to provide bus slaves with large queues that can store significant numbers of issued transfer requests. Storing the transfer requests frees up the network transfer request paths. If there is no congestion in the network transfer request path, data transfer requests can reach the arbitration end node in a short time so that high priority transfer requests are not ignored by the arbitration end node for a long time.
This queue solution has several drawbacks. Most slaves do not need large queues to arbitrate among waiting transfer requests to achieve optimization goals. For these slaves parking queues are a waste of area. For each slave, the queue should be large enough to store a number of transfer requests that is greater than or equal to the total number of transfer requests that may be issued collectively by all the masters connected to the slave. This is often not the case. If one of the slave parking queues fills up because it is not sized correctly, transactions may be backed up in the interconnect.
Due to ordering constraints on the bus or related deadlock problems, it may be impossible or complex to issue more than one transfer request at a time through a bus switch node when two or more destinations are implied. Some examples of ordering constraints are the situations observed at bus switch nodes for Advanced Microcontroller Bus Architecture (AMBA) Advanced eXtensible Interface (AXI) bus write transactions to two or more destinations and for AMBA AXI bus read transactions to two or more destinations with the same ID. A slave queue may be capable of storing more transaction requests but the network intrinsically can no longer issue more transaction requests. In these situations, an arbitration node can still block a high priority request upstream in the network transfer request path because locally at the arbitration node a slightly higher priority is given to another branch of the network, or because a fair use algorithm grants the ignored critical network branch later, or because by default a bandwidth optimization is running when no urgency is seen at the arbitration node. In these situations, the arbitration scheme is inconsistent throughout the overall bus network, resulting in stability and performance problems.
Other solutions have been proposed to circumvent some of the problems described above, including restraining the number of requests or the request rate at the masters to avoid network and slave queue congestion, local bandwidth reservation at the network nodes, longer slave queues with queue room reservation for some critical masters, enlarged or duplicated bus layers. These solutions, however, often require increased logic complexity or have over constraints that may prevent bandwidth optimization.
Bus protocols with no outstanding transactions support and strongly ordered bus protocols, such as AMBA High Speed Bus (AHB) protocol, are even more problematic because they do not provide native quality of service support. Busses that implement these protocols have the advantage of small area and latency, but they also have stability and performance issues that prevent these busses from having a consistent and efficient system wide arbitration scheme.